Skip to content

fix(maven): replace internal MavenGeneralSettings.getLocalRepository() API#255

Merged
ruromero merged 1 commit into
redhat-developer:mainfrom
ruromero:TC-4168
Apr 20, 2026
Merged

fix(maven): replace internal MavenGeneralSettings.getLocalRepository() API#255
ruromero merged 1 commit into
redhat-developer:mainfrom
ruromero:TC-4168

Conversation

@ruromero

@ruromero ruromero commented Apr 20, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Replace MavenGeneralSettings.getLocalRepository() (internal API in IC-252) with MavenProjectsManager.getInstance(project).getRepositoryPath() (public in both 2025.1 and 2025.2)
  • Extract project resolution into a reusable getProject() helper in MavenSettingsUtil
  • No changes to getUserSettingsFile(), getMavenHomeType(), or MavenWrapper — all confirmed public

Implements TC-4168

Test plan

  • ./gradlew compileJava passes
  • ./gradlew verifyPluginMavenGeneralSettings.getLocalRepository() no longer flagged
  • ./gradlew test — all existing tests pass
  • Manual: open a Maven project, confirm component analysis resolves correct local repo

🤖 Generated with Claude Code

…) API

Use MavenProjectsManager.getRepositoryPath() which is public in both
IntelliJ 2025.1 and 2025.2, instead of the internal getLocalRepository()
method that was marked @ApiStatus.Internal in IC-252.

Implements TC-4168

Assisted-by: Claude Code
@qodo-code-review

Copy link
Copy Markdown

Review Summary by Qodo

Replace internal Maven API with public alternative

🐞 Bug fix

Grey Divider

Walkthroughs

Description
• Replace internal MavenGeneralSettings.getLocalRepository() with public
  MavenProjectsManager.getRepositoryPath() API
• Extract project resolution logic into reusable getProject() helper method
• Ensure compatibility with IntelliJ 2025.1 and 2025.2 public APIs
Diagram
flowchart LR
  A["MavenSettingsUtil.getLocalRepository()"] -->|"old: internal API"| B["MavenGeneralSettings.getLocalRepository()"]
  A -->|"new: public API"| C["MavenProjectsManager.getRepositoryPath()"]
  D["getProject() helper"] -->|"used by"| A
  D -->|"used by"| E["getMavenGeneralSettings()"]
Loading

Grey Divider

File Changes

1. src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java 🐞 Bug fix +11/-10

Replace internal Maven API with public alternative

• Added import for MavenProjectsManager to access public repository path API
• Extracted project resolution logic into new private getProject() helper method
• Refactored getMavenGeneralSettings() to use the new getProject() helper
• Replaced MavenGeneralSettings.getLocalRepository() call with
 MavenProjectsManager.getInstance(getProject()).getRepositoryPath().toString() in
 getLocalRepository() method

src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java


Grey Divider

Qodo Logo

@qodo-code-review

qodo-code-review Bot commented Apr 20, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Mixed project Maven settings 🐞 Bug ≡ Correctness
Description
MavenSettingsUtil.getLocalRepository() now resolves the repo path from
MavenProjectsManager.getInstance(getProject()) on every call, while
getUserSettingsFile()/isMavenWrapperSelected() use a static cached MavenGeneralSettings captured
once. If the set/order of open projects changes (or multiple projects are open), ApiService can
export Maven user settings from one project and the local repository from another, producing
incorrect Maven environment properties for analysis.
Code

src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java[R45-46]

    public static String getLocalRepository() {
-        MavenGeneralSettings settings = getMavenGeneralSettings();
-        return settings.getLocalRepository();
+        return MavenProjectsManager.getInstance(getProject()).getRepositoryPath().toString();
Evidence
MavenGeneralSettings is cached statically after the first call and is tied to whatever getProject()
returned at that moment, but getLocalRepository() bypasses that cache and re-queries getProject()
each time. ApiService reads both values in the same request when setting system properties, so a
project mismatch results in inconsistent Maven config being sent to the backend.

src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java[13-32]
src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java[45-47]
src/main/java/org/jboss/tools/intellij/exhort/ApiService.java[153-165]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`MavenSettingsUtil.getLocalRepository()` now derives the repository path from `MavenProjectsManager.getInstance(getProject())` each call, while other Maven settings (`getUserSettingsFile()`, `isMavenWrapperSelected()`) are derived from a statically cached `MavenGeneralSettings` captured once. This can mix settings across different open projects.

### Issue Context
`ApiService#setRequestProperties` sets multiple Maven-related system properties in one call path. These values must be resolved from the same `Project` instance to avoid exporting an inconsistent Maven configuration.

### Fix Focus Areas
- Align all Maven settings methods to use the same `Project` instance (preferably passed in from the caller rather than using `openProjects[0]`).
- Remove/avoid static cross-project caching of `MavenGeneralSettings`, or cache per-project if caching is required.

- src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java[13-47]
- src/main/java/org/jboss/tools/intellij/exhort/ApiService.java[153-165]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

@sonarqubecloud

Copy link
Copy Markdown

Comment on lines 45 to +46
public static String getLocalRepository() {
MavenGeneralSettings settings = getMavenGeneralSettings();
return settings.getLocalRepository();
return MavenProjectsManager.getInstance(getProject()).getRepositoryPath().toString();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Mixed project maven settings 🐞 Bug ≡ Correctness

MavenSettingsUtil.getLocalRepository() now resolves the repo path from
MavenProjectsManager.getInstance(getProject()) on every call, while
getUserSettingsFile()/isMavenWrapperSelected() use a static cached MavenGeneralSettings captured
once. If the set/order of open projects changes (or multiple projects are open), ApiService can
export Maven user settings from one project and the local repository from another, producing
incorrect Maven environment properties for analysis.
Agent Prompt
### Issue description
`MavenSettingsUtil.getLocalRepository()` now derives the repository path from `MavenProjectsManager.getInstance(getProject())` each call, while other Maven settings (`getUserSettingsFile()`, `isMavenWrapperSelected()`) are derived from a statically cached `MavenGeneralSettings` captured once. This can mix settings across different open projects.

### Issue Context
`ApiService#setRequestProperties` sets multiple Maven-related system properties in one call path. These values must be resolved from the same `Project` instance to avoid exporting an inconsistent Maven configuration.

### Fix Focus Areas
- Align all Maven settings methods to use the same `Project` instance (preferably passed in from the caller rather than using `openProjects[0]`).
- Remove/avoid static cross-project caching of `MavenGeneralSettings`, or cache per-project if caching is required.

- src/main/java/org/jboss/tools/intellij/settings/MavenSettingsUtil.java[13-47]
- src/main/java/org/jboss/tools/intellij/exhort/ApiService.java[153-165]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@ruromero
ruromero merged commit 9e75dcc into redhat-developer:main Apr 20, 2026
9 checks passed
@ruromero
ruromero deleted the TC-4168 branch April 20, 2026 21:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant